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System for secure transactions 
BACKGROUND OF THE INVENTION 

The invention relates to a system for the execution of 
6 secure transactions in a multimecJia network* 

Multimedia networks like the Internet offer a wide variety 
of new possibilities, which will have a great impact on the 
business environment of the future. Various vendors will 
start to exploit the Internet as a marketplace. For a 
10 customer not to get lost within the vast amount of 

information that is provided, in the near future agent- 
based services shall be implemented • Agents are autonomous 
^ pieces of software/ which may perform tasks for users on 
the Internets Based on the user's preferences, they may 
15 assist the user in making a selection within the vast range 
of offered poducts- Complementary to this^ the agent may 
assist in the actual purchase of such a product. As part of 
this process, the agent will have to be able to perform 
payments • 

20 One of the biggest inhibitors on Electronic Commerce today 
is security. Consumers demand that their private 
information be kept private* When using agent technology 
within an E-Commerce service, adequate security precautions 
must be taken. At present, however, agent security is still 
1^25 in its infancy. Therefore, delegating payments to agents is 
not possible at this moment in time, 
SUMMARY OF THE INVENTION 

According to the present invention, an architecture is 
proposed in which agents may perform secure credit card 
30 payments. According to the invention, for the execution of 
such payments the SET (Secure Electronic Transactions) 
protocol is used, an upcoming standard for secure payments 
on the Internet by means of credit cards. All new entities 
and components that are necessary to provide agent-based 



SET payments will be defined and payment interaction 
(agent-agent, agent-user and other) will be elaborated 
upon. 

Most entities of the standard infrastructure for performing 
5 SET-based payments by means of credit cards are 

straightforward analogies to real world credit card 
payments. A few, however, need further explanation. A brief 
description of these will be given first. 
One of the main issues when providing secure payments is 
10 authentication of the involved entities. SET uses a robust 
set of digital certificates for this purpose. Each 
participant in a SET transaction requires a specific 
certificate or set of certificates that not only iiniquely 
identifies this participant, but also attests to his or her 
15 privilege as holder of a payment card or as a holder of a 
Merchant account. Brand Associations (e.g. VISA/ 
MasterCard) or Card Issuers commission so called 
Certificate Authorities (CAs) to carry out the work of 
managing SET digital certificates. 
20 Complementary to this, SET introduces the notion of a 

Payment Gateway, which is needed to validate SET digital 
certificates and preprocess authorisation, capture and 
settlement work concerning the payment at hand* Another 
fundamental requirement for performing SET payments is a 
25 component called an Electronic Wallet (E-Wallet) . These 
wallets embody the SET protocol on the customer side and 
provide a means to store and manage the certificates to 
digitally sign messages, along with the security aspects 
consumers demand to keep private data private* 
30 According to the present invention the task of performing 
SET credit card transactions is delegated to agents* In 
developing an infrastructure that enables this, the 
following constraints have been defined: 

- Obtaining certificates is not a task that users will want 
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to delegate to their agents* Furthermore, it is not very 
probable that banks and CAs will approve of this situation. 
Therefore, we assume all certificates and the E-Wallet to 
be in place. 

5 - The standard SET infrastructure shall be kept intact. 

Thereby the inherent security of SET payments shall remain 
present and the necessary alterations when implementing 
shall be limited. 

Based on these constraints, an infrastructure has been 
10 designed wich will be discussed below. 

EMBODIMENT OF THE INVENTION 

Figure 1 shows an architecture in which the invention -the 
use the SET protocol by "secure agents^ can be implemented. 
Figure 1 shows a multimedia network -the internet- 1. 

15 Connected to the internet 1 are customer PCs 2, and 

merchant servers 3, each via an internet service providers 
(ISP) 4. Also connected to the internet, via an ISP 4/ is a 
payment (gateway) server 5. The payment server 5 is also - 
via an access server 6- connected to a "Banker's 

20 Interchange Network" (BIN) 7, having banking servers 8 
connected to it. 

A main issue in secure payments is authentication of 
entities. The SET protocol ^ to be used in the system shown 
I in figure 1, uses a set of digital certificates for this 
25 purpose. Each participant in transaction rec^uires a 

certificate that uniquely identifies the participant and 
also attests to his privilege as a holder of a account at 
the merchant server. Associations like VISA/MasterCard or 
other Card Issuers commission so called Certificate 
30 Authorities to carry out the work of managing SET digital 
certificates. In figure 1 a Trusted Third Party Server 
(TTPS) 9 of such Certificate Authority is connected to the 
internet 1 and can be approached by customers 2f merchants 



3 and payment servers 5. Payment servers 5 are needed to 
validate the digital certificates and to preprocess 
authorisation^ capture and settlement work concerning the 
payment . 

5 Another fundamental requirement for performing SET payments 
is a system component called "Electronic Wallet" (EM) 10, 
An E-wallet 10 embodies the SET protocol at the customer's 
side and provides means — within the customer's PC 2 — to 
store and manage the needed certificates, to digitally sign 

10 messages, along with the security aspects customers demand 
to keep private data private* 

According to the invention agents are used to perform 
secure transactions* As said before, agents are autonomous 
pieces of software, which are enabled to perform tasks for 

IS users (customers or merchants) , Based on preferences set by 
users 2 (customer) and 3 (merchant), the users* respective 
agents assists or represent the users in presenting and 
selecting of the merchants' products and, complementary to 
this, the users* respective agents assist or represents the 

20 users to purchase (collect) the selected products and to 
perform the secure payment for it* 

Each customer 2 may be represented by a customer agent 
(CA) , while each merchant 3 may be represented by a 
merchant agent (MA) , The negotiation process (presentation, 

25 selection and collection of products and the payments for 
the collected products) is executed within an "agent 
platform", preferably embodied within an "Agent Negotiation 
Server" (ANS) 11. Communication between the customer's PC 3 
and the customer's agent at the ANS's side is performed, at 

30 the customer's side via the E-wallet 10 — meant for SET 
based transaction — which is extended with a special SET 
Agent Interface (SAI) 12. 

The CA 13 communicates with the customer by means of the 



:'llhf^tep:d6|i^-1^^ 



-5- 

customer's "browser" (customer inferface) and, via the SAI 
12, with the customer's E-wallet 10 in order to initialise 
payments. As was the case according to the state-of-the-art 
(using credit cards), the actual SET payment process is 
S performed between the E-Wallet 10 and the Merchant server 
3. Therefore, during actual payment interaction the level 
of trust is the same as in known, credit card based SET 
payments , 

The CA 13 will have to be authorised to initialise the EW 
10 10 for payments. In standard SET transactions the customer 
is prompted — via the customer's browser — to enter the E- 
Wallet password for this purpose. The CA 13 and the SAI 12 
will have to be implemented such, that one of two scenarios 
may be performed: either the CA 13 has authorisation to 
15 release the cryptographic content of the E-Wallet 10 

itself, or, after agent initialisation, the customer is 
prompted to provide an E-Wallet password. In the latter 
case, customer interaction is necessary. This is not 
desirable from a usability point of view, but might be 
20 preferred by customers (or merchants), since this will give 
them a sense of control over the payment - 
Figure 2 shows a communication procedure for the system 
presented in figure 1 . 
I For authentication and authorisation purposes, the CA 13 

25 will carry a token, in which an authorisation code for 

opening up the E-Wallet is encapsulated. The level at which 
this token is secured within the agent depends on the 
location of the platform in which the CA 13 performs its 
tasks. If this platform resides on the customer PC, 
30 security requirements on both storing the token within the 
agent and communicating it to the E-Wallet are less strong 
than if the agent resides on a remote platform like the ANS 
11 as suggested in figure 1. In the latter case, the token 
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will need to be adequately secured/ as will- communication 
between the agent and the E-Wallet. The security 
requirements are as follows: 

The token is stored within the CA 13 in encrypted form, 
5 using a random key* A symmetric encryption scheme, such 
as DES, shall be applied here* This random key is 
generated at the PC 2 for each specific purchase* A new 
key shall be generated for each item that is to be bought 
by the agent • 

10 For communication purposes, both the customer 2 and the 
CA 13 need to own a specific certificate, other than the 
SET certificate* Payment start messages shall be 
communicated to the E-Wallet 10 in encrypted form, using 
a random session key. A symmetric encryption scheme, such 
15 as DES, shall be applied here. In turn, this random key 
shall be sent over in encrypted form, using the 
customer's public key related to the communication 
certificate- The message shall be signed with the agent's 
private key and a time stamp shall be added to the 
20 message in order to prevent replay by malicious parties. 
In figure 2 the following communication steps are 
performed: 

In step I, the CA 13 requests the Merchant Agent (MA) 14 
to pay by credit card. The latter then informs the 
25 merchant server 3 of the requested payment, while 
parallell to that the CA 13 initialises the EW 10. 

In step II, the standard SET procedure is performed by 
the EW 10 r the Merchant server 3 and the Payment Gateway 
server 5* 

30 Finally, in step 111, after completion of the payment, 

the Merchant server 3 informs the MA 14 of this fact. The 
MA 14 passes this message on to the CA 13, which notifies 
the customer of payment completion. 
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The infrastructure and message flows are a natural 
extension of any agent-based infrastructure. Impleraentat 
may therefore by performed straightforwardly. 
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CLAIMS 

1. System for the execution of secure transactions in a 
multimedia network, comprising a multimedia network with 
customer stations (2), merchant servers (3), and a payment 
5 server (5) connected to it, secure electronic transactions 
being performed using a secure electronic transactions 
protocol, comprising the exchange of digital certificates, 
uniquely identifying the relevant transaction participants 
and also attesting their privileges at the merchant server, 
10 said certificates being managed by a Trusted Third Party 
server (9) being connected too to said multimedia network, 
# said payment servers 5 being enabled to validate the 

digital certificates presented and to process authorisation 
concerning the payment, said customer stations comprising 
15 transactions management means (10), fit for performing said 
secure electronic transactions protocol and for managing 
said certificates for the customer station, 
characterized in a remote customer agent 
(13) , managed by agent parameters received or to be 
20 received from said customer station (2) and thus, under the 
control of said parameters, assisting or representing the 
customer station in a negotiation process, including 
selecting products to be presented by the merchant server 
^ (3), and payment for selected products in a secure way, 

^ 25 under control of said secure electronic transactions 
protocol and said certificates, being managed by said 
transactions management means (10) . 
2. System according to claim 1, 

characterized in that said customer station 
30 (2) comprises an agent interface 12, fit for transmission 
of codes, parameters and certificates between said customer 
agent (13) and said transactions management means (10) . 
3. System according to claim 1, 
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characterized in a remote merchant agent 
(14), managed by agent parameters received or to be 
received from said merchant station (3) and thus, under the 
control of said parameters, assisting or representing the 
merchant station in a negotiation process, including 
presenting products to the customer agent (13) or the 
customer station (3) , and to have paid for products being 
selected by the customer agent (13) or the customer station 
(3) , in a secure way, under control of said secure 
electronic transactions protocol and said certificates. 

4. System according to claim 2, 

characterized in that said negotiation and 
payment process by said customer agent (13) and said 
merchant agent (14) is performed within an agent 
15 negotiation server (11) , connected to said multimedia 
network (1) . 

5. System according to claim 1, 

characterized in that, within said secure 
electronic transaction protocol, for authentication and 
20 authorisation said customer agent (13) transmits a token is 
encapsulated, comprising an authorisation code for opening 
up said transactions management means (10) . 

6, System according to claim 5, 

characterized in that said token is stored 
25 within the customer agent (13) in an encrypted form, using 
a random key, being generated at the customer station (2) 
for each new payment process. 

7. System according to claim 5, 

characterized in that both the customer 
30 station (2) and the customer agent (13) comprise a specific 
communication certificate, payment start messages being 
communicated to said transactions management means (10) in 
encrypted form, using a random session key which, in turn. 
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is sent over in encrypted form, using the customer 
station's public key related to said communication 
certificate, said message being signed with the customer 
agent's private key related to said communication 
5 certificate and a time stamp being added to said message xn 
order to prevent replay by malicious partxes . 
8 Method for the execution of secure transactxons xn a 
multimedia network, comprising a multimedia network wxth 
customer stations (2), merchant servers (3), and a payment 
10 server (5) conx^ected to it, secure electronic transactxons 
being performed using a secure electronic transactxons 
» protocol, comprising the exchange of digital --^^^-^^^^^ 
uniquely identifying the relevant transactxon partxcxpants 
and also attesting their privileges at the --^^^ 
15 said certificates being managed by a Trusted Thxrd Party 
server (9) being connected too to said multimedia network, 
said payment servers 5 being enabled to validate the 
digital certificates presented and to process authorisation 
concerning the payment, said customer stations comprising 
20 transactions management means (10), fit for performing saxd 
secure electronic transactions protocol and for managing 
said certificates for the customer station, moreover, 
comprising a remote customer agent (13) , managed by agent 
_ parameters received or to be received from said customer 

• 25 station (2) and thus, under the control of said parameters, 
assisting or representing the customer station in a 
negotiation process, including selecting products to be 
presented by the merchant server (3), and payment for 
selected products in a secure way, under control of saxd 
30 secure electronic transactions protocol and saxd 

certificates, being managed by said transactions management 
means (10), while, moreover, said customer station (2) 
comprises an agent interface (12), fit for transmission of 
codes, parameters and certificates between said customer 
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agent (13) and said transactions management means (10), 
and, besides, a remote merchant agent (14) , managed by 
agent parameters received or to be received from said 
merchant station (3) and thus, vnder the control of said 
parameters, assisting or representing the merchant station 
in a negotiation process, including presenting products to 
the customer agent (13) or the customer station (3), and to 
have paid for products being selected by the customer agent 
(13) or the customer station (3) , in a secure way, under 
control of said secure electronic transactions protocol and 
said certificates, characterized in the 
following communication steps: 

in a first step, said customer agent (13) requests said 
merchant agent (14) to pay by credit card, and the merchant 
agent then informs said merchant server (3) of the 
requested payment, while parallell to that the the customer 
agent (13) initialises said transactions management means 
(10) ; 

in a second step, a standard secure electronic transaction 
procedure is performed by the transactions management means 
(10), the merchant server (3) and the payment gateway 
server (5) ; 

in a third, final step, after completion of the payment 
process, the merchant server (3) informs the merchant agent 
25 (14) of that completion of the payment process, and the 
merchant agent (14) passes this message on to the customer 
agent (13) , which notifies the customer station (2) of the 
payment completion. 



20 
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ABS TRACT 

A multimedia network (1, with connected ^^^^^V ,T^TZr. 
(2) , merchant servers (3) , and a payment server (5) . secure 
electronic transactions are performed using a secure 
S electronic transactions protocol (SE., , Including exchange 
of digital certificates, managed by a Trusted Thxrd Party 
server (9) - The customer stations comprise transactions 

" .in, f.f r„j: oerforming said SET protocol 

management means (10), fit ror periot i 

and for managing said certificates for the customer 

,0 station. A remote customer agent (13) represents the 

customer station in the negotiation and payment P^°«": 

The customer station (2) comprises an agent ^terface (12W 

fit for transmission of codes, parameters and certificates 

1. _ n and the transactions 

between the customer agent 113) ana T:ne 

15 laanagement means (10). A remote merchant agent (14) 

represents the merchant station (3) in the negotxatxon and 
payment process with the customer agent (13) or the 
customer station (3), to have paid for the -^^^^^^ 
products in a secure way, under coni:rol of SET protocol. 

20 (Fig. 1) 
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